# 01장 객체, 설계
Assembled by GimunLee
# 프로그래밍 패러다임
프로그래밍 패러다임(programming paradigm)은 특정 시대의 어느 성숙한 개발자 공동체 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일이라고 할 수 있다. 간단히 말해서 우리가 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다.
프로그래밍 패러다임의 중요성
- 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 함으로써 불필요한 부분에 대한 의견 충돌을 방지한다.
- 프로그래밍 패러다임을 교육시킴으로써 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 준비시킬 수 있다.
이러한 프로그래밍 패러다임은 과거의 패러다임을 폐기시키는 혁명적인 과정을 거치지 않고, 오히려 과거에 있던 패러다임의 단점을 보완하는 발전적인 과정을 거치는 것으로 보인다. 간단히 말해 프로그래밍 패러다임은 혁명적(revolutionary)이 아니라 발전적(evolutionary)이다. 이런 사실은 비록 객체지향 패러다임을 주로 사용한다고 하더라도 다른 패러다임을 배우는 것이 도움이 될 것이라는 사실을 암시한다. 또한 객체지향이 적합하지 않은 상황에서는 언제라도 다른 패러다임을 적용할 수 있는 시야를 기르고 지식을 갈고 닦아야 한다.
# 01. 티켓 판매 애플리케이션 구현하기
# 요구사항
- 공연을 무료로 관람할 수 있는 이벤트 초대장을 갖고 있는 관람객은 초대장을 티켓으로 교환한 후에 입장할 수 있다.
- 이벤트 초대장을 갖고 있지 않은 관람객은 티켓을 구매해야만 입장할 수 있다.
위와 같은 요구사항을 만족시키기 위해서는 관람객을 입장시키기 전에 이벤트 당첨 여부를 확인해야 하고 이벤트 당첨자가 아닌 경우에는 티켓을 판매한 후에 입장시켜야 한다.
# Step 01
그림 1.1 애플리케이션의 핵심 클래스
# 애플리케이션의 핵심 클래스 설명
Invitation : 공연을 관람할 수 있는 초대일자(when)를 인스턴스 변수로 포함하는 간단한 클래스다.
public class Invitation { private LocalDateTime when; }Tickect : 공연을 관람하기 원하는 모든 사람들은 티켓을 소지하고 있어야만 한다.
public class Ticket { private Long fee; public Long getFee() { return fee; } }Bag : 이벤트 당첨자는 티켓으로 교환할 초대장을 가지고 있고, 당첨되지 않은 관람객은 티켓을 구매할 수 있는 현금을 보유하고 있을 것이다. 따라서 관람객이 가지고 올 수 있는 소지품은 초대장, 현금, 티켓 세 가지뿐이다.
public class Bag { private Long amount; private Invitation invitation; private Ticket ticket; public Bag(Long amount) { this(null, amount); } public Bag(Invitation invitation, Long amount) { this.invitaion = invitation; this.amount = amount; } public boolean hasInvitation() { return invitation != null; } public boolean hasTicket() { return ticket != null; } public void setTicket(Ticket ticket) { this.ticket = ticket; } public void minusAmount(Long amount) { this.amount -= amount; } public void plusAmount(Long amount) { this.amount += amount; } }Audience : 관람객은 소지품을 보관하기 위해 가방을 소지할 수 있다.
public class Audience { private Bag bag; public Audience(Bag bag) { this.bag = bag; } public Bag getBag() { return bag; } }TicketOffice : 관람객이 소극장에 입장하기 위해서는 매표소에서 초대장을 티켓으로 교환하거나 구매해야 한다. 따라서 매표소에는 관람객에게 판매할 티켓과 티켓의 판매 금액이 보관돼 있어야 한다.
public class TicketOffice { private Long amount; private List<Ticket> tickets = new ArrayList<>(); public TicketOffice(Long amount, Ticket ... tickets) { this.amount = amount; this.tickets.addAll(Arrays.asList(tickets)); } public Ticket getTicket() { return tickets.remove(0); } public void minusAmount(Long amount) { this.amount -= amount; } public void plusAmount(Long amount) { this.amount += amount; } }TicketSeller : 판매원은 매표소에서 초대장을 티켓으로 교환해 주거나 티켓을 판매하는 역할을 수행한다. 판매원을 구현한 TicketSeller 클래스는 자신이 일하는 매표소(tickectOffice)를 알고 있어야 한다.
public class TicketSeller { private TicketOffice ticketOffice; public TicketSeller(TicketOffice ticketOffice) { this.ticketOffice = ticketOffice; } public TicketOffice getTicketOffice() { return ticketOffice; } }Theater : 소극장을 구현하는 클래스로 관람객을 맞이할 수 있도록 enter 메서드를 구현하자.
public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSeller = ticketSeller; } public void enter(Audience audience) { // 관람객 맞이 // 가방에 초대장이 있는지 확인 if (audience.getBag().hasInvitation()) { // 초대장이 있다면, Ticket ticket = ticketSeller.getTicketOffice().getTicket(); // 티켓 발급 audience.getBag().setTicket(ticket); // 관람객에게 티켓 전달 } else { // 초대장이 없다면, Ticket ticket = ticketSeller.getTicketOffice().getTicket(); // 티켓 발급 audience.getBag().minusAmount(ticket.getFee()); // 티켓 가격 차감 ticketSeller.getTicketOffice().plusAmount(ticket.getFee()); // 매표소 현금 올리기 audience.getBag().setTicket(ticket); // 관람객에게 티켓 전달 } } }
작성된 프로그램의 로직은 간단하고 예상대로 동작한다. 하지만 안타깝게도 이 작은 프로그램은 몇 가지 문제점을 가지고 있다.
# 02. 무엇이 문제인가
로버트 마틴은 클린 소프트웨어에서 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명한다. 여기서 모듈이란 크기와 상관없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미한다.
- 실행 중에 제대로 동작해야 한다. 이것은 모듈의 존재 이유라고 할 수 있다.
- 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.
- 코드를 읽는 사람과 의사소통하는 것이다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할수 있어야 한다.
앞서 작성한 프로그램은 관람객들을 입장시키는 데 필요한 기능을 오류 없이 정확하게 수행하고 있다. 따라서 제대로 동작해야 한다는 제약은 만족시킨다. 하지만 변경 용이성과 읽는 사람과의 의사소통이라는 목적은 만족시키지 못한다.
# 예상을 빗나가는 코드
Theater 클래스의 enter 메서드가 수행하는 일을 말로 풀어보자.
소극장은 관람객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴본다. 가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다 가방 안에 초대장이 들어 있지 않다면 관람객의 가방에서 티켓 금액만큼의 현금을 꺼내 매표소에 적립한 후에 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.
여기서 문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다. 다시말해 소극장이라는 객체가 돈과 티켓을 조작하는 일을 수행한다. 이것은 우리의 상식과는 너무나도 다르게 동작하기 때문에 코드를 읽는 사람과 제대로 의사소통하지 못한다.
또한 이 코드를 이해하기 위해서는 여러 가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점이다. Theater의 enter 메서드를 이해하기 위해서는 Audience가 Bag를 가지고 있고, Bag 안에는 현금과 티켓이 들어 있으며 TicketSeller가 TicketOffice에서 티켓을 판매하고, TicketOffice 안에 돈과 티켓이 보관돼 있다는 모든 사실을 동시에 기억하고 있어야 한다. 이코드는 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 때문에 코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해해야 하는 사람 모두에게 큰 부담을 준다.
하지만 가장 심각한 문제는 Audience와 TickectSeller를 변경할 경우 Theater도 함께 변경해야 한다는 사실이다.
# 변경에 취약한 코드
이 코드는 관람객이 현금과 초대장을 보관하기 위해 항상 가방을 들고 다닌다고 가정한다. 또한 판매원이 매표소에서만 티켓을 판매한다고 가정한다. 관람객이 가방을 들고 있지 않다면 어떻게 해야할까? 관람객이 현금이 아니라 신용카드를 이용해서 결제한다면 어떻게 해야 할까? 이런 가정이 깨지는 순간 모든 코드가 일시에 흔들리게 된다.
이것은 객체 사이의 **의존성(dependency)**과 관련된 문제다. 문제는 의존성이 변경과 관련돼 있다는 점이다. 의존성의 변경에 대한 영향을 암시한다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있다.
그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다. 따라서 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
그림 1.2 너무 많은 클래스에 의존하는 Theater
위와 같이 객체 사이의 의존성이 과한 경우를 가리켜 **결합도(Coupling)**가 높다고 말한다. 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말한다. 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다. 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다. 따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
# 03. 설계 개선하기
현재 변경과 의사소통이라는 문제가 서로 엮여 있다는 점에 주목하라. 코드를 이해하기 어려운 이유는 Theater가 관람객의 가방과 판매원의 매표소에 직접 접근하기 때문이다. 이것은 관람객과 판매원이 자신의 일을 스스로 처리해야 한다는 우리의 직관을 벗어난다. 또한 Theater가 관람객의 가방과 판매원의 매표소에 직접 접근한다는 것은 Theater가 Audience와 TicketSeller에 결합된다는 것을 의미한다.
해결 방법은 간단하다. Theater가 Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. 사실 관람객이 가방을 가지고 있다는 사실과 판매원이 매표소에서 티켓을 판매한다는 사실을 Theater가 알아야 할 필요가 없다. Theater가 원하는 것은 관람객이 소극장에 입장하는 것 뿐이다. 따라서 관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다면 이 모든 문제를 한 번에 해결할 수 있을 것이다.
다시 말해서 관람객과 판매원을 자율적인 존재로 만들면 되는 것이다.
# 자율성을 높이자
그림 1.6 자율적인 Audience와 TicketSeller로 구성된 설계
# TicketSeller의 자율성 높이기
해결 방법은 Theater의 enter 메서드에서 TicketOffice에 접근하는 모든 코드를 TicketSeller 내부로 숨기는 것이다. TicketSeller에 sellTo 메서드를 추가하고 Theater에 있던 로직을 이 메서드로 옮기자.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
if (audience.getBag().hasInvitation()) {
Ticket ticket = ticketOffice.getTicket();
audience.getBag.setTicket(ticket);
}
else {
Ticket ticket = ticketOffice.getTicket();
audience.getBag().minusAmount(ticker.getFee());
ticketOffice().plusAmount(ticket.getFee());
audience.getBag.setTicket(ticket);
}
}
}
이때 TicketSeller에서 getTicketOffice 메서드가 제거됐다는 사실에 주목하라. ticketOffice의 가시성이 private이고 접근 가능한 퍼블릭 메서드가 더 이상 존재하지 않기 때문에 외부에서는 ticketOffice에 직접 접근할 수 없다. 결과적으로 ticketOffice에 대한 접근은 오직 TicketSeller 안에만 존재하게 된다. 따라서 TicketSeller는 ticketOffice에서 티켓을 꺼내거나 판매 요금을 적립하는 일을 스스로 수행할 수밖에 없다.
이처럼 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 **캡슐화(encapsulation)**라고 부른다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.
이제 Theater의 enter 메서드는 sellTo 메서드를 호출하는 간단한 코드로 바뀐다.
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
public void enter(Audience audience) {
ticketSeller.sellTo(audience);
}
}
수정된 Theater 클래스 어디서도 ticketOffice에 접근하지 않는다는 사실에 주목하라. Theater는 ticketOffice가 TicketSeller 내부에 존재한다는 사실을 알지 못한다. Theater는 단지 ticketSeller가 sellTo 메시지를 이해하고 응답할 수 있다는 사실만 알고 있을 뿐이다.
Theater는 오직 TicketSeller의 **인터페이스(interface)**에만 의존한다. TicketSeller가 내부에 TicketOffice 인스턴스를 포함하고 있다는 사실은 **구현(implementation)**의 영역에 속한다. 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.
# Audience의 자율성 높이기
TicketSeller는 성공적으로 캡슐화가 되었다. 이제 TicketSeller가 Audience의 인터페이스에만 의존하도록 수정하자. TicketSeller가 buy 메서드를 호출하도록 코드를 변경하면 된다.
public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
public Long buy(Ticket ticket) {
if (bag.hasInvitation()) {
bag.setTicket(ticket);
return 0L;
}
else {
bag.setTicket(ticket);
bag.minusAmount(ticker.getFee());
return ticket.getFee();
}
}
}
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
}
}
이제 관람객은 자신의 가방안에 초대장이 있는지 스스로 확인한다. 더 이상 제3자가 자신의 가방을 열어보도록 허용하지 않는다. 또한 Audience가 Bag를 직접처리 하기 때문에 외부에서는 더 이상 Bag의 소유 여부를 알 필요가 없다.
TicketSeller와 Audience 사이의 결합도가 낮아졌고 내부 구현이 캡슐화되었기 때문에 Audience의 구현을 수정하더라도 TicketSeller에는 영향을 미치지 않는다. TicketSeller와 Audience는 더 이상 내부 구현을 노출하지 않고 자신의 문제를 스스로 책임지고 해결한다. 즉, 자율적인 존재가 되었다.
# 무엇이 개선됐는가
TicketSeller와 Audience는 자신이 가지고 있는 소지품을 스스로 관리하고 이것은 우리의 예상과도 일치한다. 따라서 코드를 읽는 사람과의 의사소통이 개선되었다.
또한 TicketSeller와 Audience의 내부 구현을 변경하더라도 Theater를 함께 변경할 필요가 없다. TicketSeller이 은행에 돈을 보관하고 싶거나 Audience이 가방이 아닌 지갑을 소지하도록 변경한다면 해당 Class만 변경하면 된다. 따라서 변경 용이성 측면에서도 개선되었다.
# 어떻게 한 것인가
자기 자신이 문제를 스스로 해결하도록 코드를 변경하였고 그 결과, 이해하기 쉽고 유연한 설계를 얻을 수 있었다.
# 캡슐화와 응집도
핵심은 객체 내부의 상태를 캡슐화 하고 객체 간에 오직 메세지를 통해서만 상호 작용 하도록 만드는 것이다. 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 **응집도(cohesion)**가 높다고 말한다. 자신의 문제를 스스로 처리하는 객체를 만들면 결합도를 낮추면서 응집도를 높일 수 있다.
객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다. 외부의 간섭을 최대한 배제하고 메세지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길인 것이다.
# 절차지향과 객체지향
수정하기 전의 코드의 관점에서 Theater의 enter 메소드는 **프로세스(Process)**이며 Audience, TicketSeller, Bag, TicketOffice는 **데이터(Data)**이다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 **절차적 프로그래밍(Procedural Programming)**이라고 부른다. 일반적으로 절차적 프로그래밍은 우리의 직관에 위배된다. 우리는 관람객와 판매원이 자신의 일을 스스로 처리할 것이라고 기대하지만 절차적 프로그래밍에서는 관람객과 판매원은 수동적인 존재일 뿐이다. 절차적 프로그래밍의 세상은 우리의 예상을 쉽게 벗어나기 때문에 코드를 읽는 사람과 원활하게 의사소통하지 못하다. 또한 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다.
변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계이다. 이것을 위해서는 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 이동시키는 것이다. 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 **객체지향 프로그래밍(Object-Oriented Programming)**이라고 한다.
훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것으로 일반적으로 객체지향이 절차지향에 비해 변경이 유연하다고 하는 이유가 바로 이것이다. 객체지향 코드는 자신의 문제를 스스로 처리해야 한다는 우리의 예상을 만족시켜주기 때문에 이해하기 쉽고, 객체 내부의 변경이 객체 외부에 파급되지 않도록 제어할 수 있기 때문에 변경이 수월하다.
# 책임의 이동
절차지향과 객체지향의 근본적인 차이는 책임(기능을 가르키는 객체지향 세계의 용어)의 이동이다. 두 방식의 차이점을 가장 쉽게 이해할 수 있는 방법은 기능을 처리하는 방법을 보는 것이다.
- 변경 전의 코드는 Theater가 전체적인 작업을 처리한다.
- 변경 후의 코드는 각 객체가 자신이 맡은 일을 스스로 처리 한다.
한 곳에 몰려 있던 책임을 각 객체로 이동한 것, 이것이 책임의 이동이다. 객체지향 설계에서는 독재자가 존재하지 않고 각 객체에 책임이 적절하게 분배된다. 따라서 각 객체는 자신을 스스로 책임진다. 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성할 수 있다.
코드가 데이터와 데이터를 사용하는 프로세스가 별도의 객체에 위치하고 있다면 절차적 프로그래밍 방식을 따르고 있을 확률이 높다. 반면, 데이터와 데이터를 사용하는 프로세스가 동일한 객체 안에 위치한다면 객체지향 프로그래밍 방식을 따르고 있을 확률이 높다.
객체지향 설계의 핵심은 적절한 객체에 적절한 책임을 할당하는 것이다. 객체는 다른 객체와의 협력이라는 문맥 안에서 특정한 역할을 수행하는 데 필요한 적절한 책임을 수행해야한다. 객체가 어떤 데이터를 가지느냐보다는 객체에 어떤 책임을 할당할 것인가에 초점을 맞춰야한다. 적절한 객체에 적절한 책임을 할당하면 이해하기 쉬운 구조와 읽기 쉬운 코드를 얻게 된다.
설계를 어렵게 만드는 것은 의존성이라는 것을 기억하라. 해결 방법은 불필요한 의존성을 제거함으로 객체 사이의 결합도를 낮추는 것이다. 결합도를 낮추기 위한 한 가지 방법 중 하나는 캡슐화하는 것이다. 결과적으로 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 한다. 불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객제지향 설계이다.
# 더 개선할 수 있다
여기서 Bag는 자율적인 존재가 아니다. Bag의 내부 상태에 접근하는 모든 로직을 Bag 안으로 캡슐화해서 결합도를 낮추면 된다. Bag에 hold 메서드를 추가하자. 이제 Bag는 관련된 상태와 행위를 함께 가지는 응집도 높은 클래스가 됐다.
public class Bag {
private Long amount;
private Invitation invitation;
private Ticket ticket;
public Bag(Long amount) {
this(null, amount);
}
public Bag(Invitation invitation, Long amount) {
this.invitaion = invitation;
this.amount = amount;
}
public Long hold(Ticket ticket) {
if (hasInvitation()) {
setTicket(ticket);
return 0L;
}
else {
setTicket(ticket);
minusAmount(ticket.getFee());
return ticket.getFee();
}
}
private boolean hasInvitation() {
return invitation != null;
}
private void setTicket(Ticket ticket) {
this.ticket = ticket;
}
private void minusAmount(Long amount) {
this.amount -= amount;
}
}
public 메소드였던 hasInvitation, minusAmount, setTicket은 내부에서만 사용되기 때문에 private으로 변경했다. 메소드를 제거하지 않고 그대로 유지한 이유는 코드의 중복을 줄이고 표현력을 높이기 때문이다. 수정된 Bag에 맞게 Audience도 수정하자.
public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
public Long buy(Ticket ticket) {
return bag.hold(ticket);
}
}
TickectSeller 역시 TicketOffice의 자율권을 침해한다. TicketOffice 또한 자율적인 존재가 아니다. TickectOffice에 sellTicketTo 메서드를 추가하고 TicketSeller의 sellTo 메서드의 내부 코드를 이 메서드로 옮기자.
public class TicketOffice {
private Long amount;
private List<Ticket> tickets = new ArrayList<>();
public TicketOffice(Long amount, Ticket ... tickets) {
this.amount = amount;
this.tickets.addAll(Arrays.asList(tickets));
}
public void sellTicketTo(Audience audience) {
plusAmount(audience.buy(getTicket()));
}
private Ticket getTicket() {
return tickets.remove(0);
}
private void plusAmount(Long amount) {
this.amount += amount;
}
}
수정한 TicketOffice에 맞춰 TicketSeller도 수정한다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.sellTicketTo(audience);
}
}
이 과정에서 TicketOffice와 Audience 사이에 의존성이 추가되었다. 변경 전에서는 TicketOffice가 Audience에 대해 알지 못했지만, 변경 후에는 TicketOffice가 Audience에게 직접 티켓을 판매하기 때문에 Audience에 관해 알고 있어야 한다. 변경 전에는 존재하지 않았던 새로운 의존성이 추가되었다. 의존성의 추가는 높은 결합도를 의미하고 높은 결합도는 변경하기 어려운 설계를 의미한다.
이 예제를 통해 두 가지를 배울 수 있다.
- 첫째, 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.
- 둘째, 동일한 기능을 한가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다. 어떤 경우에도 모든 사람들을 만족시킬수 있는 설계는 만들 수 없다.
설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 명심하라.
# 그래, 거짓말이다!
실생활의 관람객과 판매자가 스스로 자신의 일을 처리하기 때문에 코드도 스스로 자신을 책임져야한다고 했다. 이것은 우리가 세상을 바라 보는 직관과도 일치한다. 이 직관에 따르는 코드는 이해하기 더 쉬운 경향이 있다. 하지만 Theater, Bag, TicketOffice는 실생활에서 자율적인 존재가 아니다. 하지만 이들을 관람객이나 판매원 같은 생물처럼 다룬다. 이를 **의인화(authropomorphism)**라고 한다.
훌륭한 객체지향 설계란 소프트웨어를 구성하는 그 대상이 비록 생명이 없는 수동적인 존재라고 하더라도 모든 객체들이 자율적으로 행동하는 설계를 말한다.
# 04. 객체지향 설계
# 설계가 왜 필요한가
설계란 코드를 배치하는 것이다.
설계를 구현과 떨어트려서 이야기하는 것은 불가능하다. 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다. 설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증이 불가능하다.
좋은 설계랑 무엇인가? 우리가 짜는 프로그램은 두 가지 요구사항을 만족시켜야 한다. 오늘 완성해야하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야한다. 좋은 설계란 오늘 요구하는 기능을 온전히 수행하며 내일의 변경을 매끄럽게 수용할 수 있는 설계이다.
변경을 수용할 수 있는 설계가 중요한 이유는 요구사항은 항상 변경되기 때문이다. 개방을 시작하는 시점에 구현에 필요한 모든 요구사항을 수집하는 것은 불가능하다. 개발을 진행하는 동안 요구사항은 변경되기 마련이다. 요구사항 변경은 필연적으로 코드 수정을 초래한다. 이러한 코드 수정은 버그가 발생할 확률을 높인다. 버그의 큰 문제는 코드를 수정하려는 의지를 꺾는다는 것이다. 즉, 코드 수정을 회피하려는 가장 큰 원인은 두려움이다. 그리고 그 두려움은 요구사항 변경으로 인해 버그를 추가할지도 모른다는 불확실성에 기인한다.
# 객체지향 설계
객체지향 프로그래밍은 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공함으로써 요구사항 변경에 좀 더 수월하게 대응할 수 있는 가능성을 높여준다. 변경 가능한 코드란 이해하기 쉬운 코드이다. 코드를 이해할 수 없으면 코드가 유연하다고 해도 수정하겠다는 마음이 들지 않는다.
객체지향 패러다임은 세상을 바라보는 방식대로 코드를 작성할 수 있게 돕는다. 세상에 대해 예상하는 방식대로 객체가 행동하리라는 것을 보장함으로써 코드를 좀 더 쉽게 이해할 수 있게 한다.
단순히 데이터와 프로세스를 객체 안에 둔다고 변경하기 쉬운 설계가 아니다. 객체지향의 세계에서 애플리케이션은 객체들로 구성되며 애플리케이션의 기능은 객체들 간의 상호작용을 통해 구성된다. 객체들의 상호작용은 객체 사이에 주고 받는 메세지로 표현된다.
애플리케이션의 기능을 구현하기 위해 객체들이 협력하는 과정 속에서 객체들은 다른 객체에 의존한다. TicketSeller가 Audience에 메세지를 보내기 위해서는 Audience에 대해 알고 있어야 한다. 메세지를 전송하기 위한 이런 지식이 두 객체를 결합시키고 이 결합이 객체 사이의 의존성을 만든다.
훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계이다. 객체가 실행되는 주변 환경에 강하게 결합될수록 변경하기 어려워진다. 객체 간의 의존성은 애플리케이션을 수정하기 어렵게 만드는 주범이다.
데이터와 프로세스를 하나의 덩어리로 모으는 것은 훌륭한 객체지향 설계로 가는 첫걸음일 뿐이다. 진정한 객체지향 설계로 나아가는 길은 협력하는 객체들 사이의 의존성을 적절하게 조절함으로써 변경에 용이한 설계를 만드는 것이다.